title: git文档10 - Git 内部原理
date: 2020.11.15 # 瞎扯
top:
tags:
10.1 底层命令与上层命令
10.2 Git 对象
10.3 Git 引用
10.4 包文件
10.5 引用规范
10.6 传输协议
10.7 维护与数据恢复
10.8 环境变量
10.9 总结
2020. 星期 :
从根本上来讲 Git 是一个内容寻址(content-addressable)文件系统,并在此之上提供了一个版本控制系统的用户界面。
本书主要涵盖了 checkout、branch、remote 等约 30 个 Git 的子命令。 这部分命令一般被称作“底层(plumbing)”命令,而那些更友好的命令则被称作“上层(porcelain)”命令。
新初始化的 .git 目录的典型结构如下:
$ ls -F1
config
description
HEAD
hooks/
info/
objects/
|- fa/38gezifu(40-2)
|- infos/
|- packs/
|- pack/
|- ORIG_HEAD
|- packed-refs
refs/
|- heads/
|- 本地的分支| dev-feature-some-20201030-updateSth
|- remotes/
|- origin/
|-tags/
|- stash
随着 Git 版本的不同,该目录下可能还会包含其他内容。 不过对于一个全新的 git init 版本库,这将是你看到的默认结构。
description 文件仅供 GitWeb 程序使用,我们无需关心。
config 文件包含项目特有的配置选项。
info 目录包含一个全局性排除(global exclude)文件, 用以放置那些不希望被记录在 .gitignore 文件中的忽略模式(ignored patterns)。
hooks 目录包含客户端或服务端的钩子脚本(hook scripts), 在 Git 钩子 中这部分话题已被详细探讨过。
剩下的四个条目很重要:HEAD 文件、(尚待创建的)index 文件,和 objects 目录、refs 目录。 它们都是 Git 的核心组成部分。
objects 目录存储所有数据内容;
refs 目录存储指向数据(分支、远程仓库和标签等)的提交对象的指针;
HEAD 文件指向目前被检出的分支;
index 文件保存暂存区信息。
Git 是一个内容寻址文件系统
它能解决文件名保存的问题,也允许我们将多个文件组织到一起。
一个树对象包含了一条或多条树对象记录(tree entry),每条记录含有一个指向数据对象或者子树对象的 SHA-1 指针,以及相应的模式、类型、文件名信息。
$ git cat-file -p master^{tree}
100644 blob a906cb2a4a904a152e80877d4088654daad0c859 README
100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 lib
master^{tree} 语法表示 master 分支上最新的提交所指向的树对象。
Figure 149. 简化版的 Git 数据模型。
因此,为创建一个树对象,首先需要通过暂存一些文件来创建一个暂存区。 可以通过底层命令 git update-index 为一个单独文件——我们的 test.txt 文件的首个版本——创建一个暂存区。
我们指定的文件模式为 100644,表明这是一个普通文件。 其他选择包括:100755,表示一个可执行文件;120000,表示一个符号链接。 这里的文件模式参考了常见的 UNIX 文件模式,但远没那么灵活——上述三种模式即是 Git 文件(即数据对象)的所有合法模式(当然,还有其他一些模式,但用于目录项和子模块)。
这就是每次我们运行 git add 和 git commit 命令时,Git 所做的工作实质就是将被改写的文件保存为数据对象, 更新暂存区,记录树对象,最后创建一个指明了顶层树对象和父提交的提交对象。 这三种主要的 Git 对象——数据对象、树对象、提交对象——最初均以单独文件的形式保存在 .git/objects 目录下。
Figure 151. 你的 Git 目录下所有可达的对象。
Git 首先会以识别出的对象的类型作为开头来构造一个头部信息,本例中是一个“blob”字符串。 接着 Git 会在头部的第一部分添加一个空格,随后是数据内容的字节数,最后是一个空字节(null byte)
就是这样——你已创建了一个有效的 Git 数据对象。
所有的 Git 对象均以这种方式存储,区别仅在于类型标识——另两种对象类型的头部信息以字符串“commit”或“tree”开头,而不是“blob”。
另外,虽然数据对象的内容几乎可以是任何东西,但提交对象和树对象的内容却有各自固定的格式。
不过你需要记得 1a410e 是你查看历史的起点提交。 如果我们有一个文件来保存 SHA-1 值,而该文件有一个简单的名字, 然后用这个名字指针来替代原始的 SHA-1 值的话会更加简单。
在 Git 中,这种简单的名字被称为“引用(references,或简写为 refs)”。
Figure 152. 包含分支引用的 Git 目录对象。
当运行类似于 git branch <branch>
这样的命令时,Git 实际上会运行 update-ref 命令, 取得当前所在分支最新提交对应的 SHA-1 值,并将其加入你想要创建的任何新引用中。
现在的问题是,当你执行 git branch
HEAD 文件通常是一个符号引用(symbolic reference),指向目前所在的分支。 所谓符号引用,表示它是一个指向其他引用的指针。
当我们执行 git commit 时,该命令会创建一个提交对象,并用 HEAD 文件中那个引用所指向的 SHA-1 值设置其父提交字段。
标签对象(tag object) 非常类似于一个提交对象——它包含一个标签创建者信息、一个日期、一段注释信息,以及一个指针。
标签对象通常指向一个提交对象,而不是一个树对象。 它像是一个永不移动的分支引用——永远指向同一个提交对象,只不过给这个提交对象加上一个更友好的名字罢了。
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2
# 现在对该 SHA-1 值运行 git cat-file -p 命令:
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
test tag
我们注意到,object 条目指向我们打了标签的那个提交对象的 SHA-1 值。 另外要注意的是,标签对象并非必须指向某个提交对象;你可以对任意类型的 Git 对象打标签。
,并保存在 refs/remotes 目录下。
这意味着,虽然你只是在一个 400 行的文件后面加入一行新内容,Git 也会用一个全新的对象来存储新的文件内容:
Git 最初向磁盘中存储对象时所使用的格式被称为“松散(loose)”对象格式。 但是,Git 会时不时地将多个这些对象打包成一个称为“包文件(packfile)”的二进制文件,以节省空间和提高效率。 当版本库中有太多的松散对象,或者你手动执行 git gc 命令,或者你向远程服务器执行推送时,Git 都会这样做。 要看到打包过程,
剩下的文件是新创建的包文件和一个索引。
包文件包含了刚才从文件系统中移除的所有对象的内容。
索引文件包含了包文件的偏移信息,我们通过索引文件就可以快速定位任意一个指定对象。
Git 是如何做到这点的? Git 打包对象时,会查找命名及大小相近的文件,并只保存文件不同版本之间的差异内容。 你可以查看包文件,观察它是如何节省空间的。 git verify-pack 这个底层命令可以让你查看已打包的内容:
同样有趣的地方在于,第二个版本完整保存了文件内容,而原始的版本反而是以差异方式保存的——这是因为大部分情况下需要快速访问文件的最新版本。
最妙之处是你可以随时重新打包。 Git 时常会自动对仓库进行重新打包以节省空间。当然你也可以随时手动执行 git gc 命令来这么做。
$ git remote add origin https://github.com/schacon/simplegit-progit
运行上述命令会在你仓库中的 .git/config 文件中添加一个小节, 并在其中指定远程版本库的名称(origin)、URL 和一个用于获取操作的 引用规范:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
## 让 Git 每次只拉取远程的 master 分支,而不是所有分支
# fetch = +refs/heads/master:refs/remotes/origin/master
## 你也可以在配置文件中指定多个用于获取操作的引用规范。
## 远程仓库获取时都包括 master 和 experiment 分支
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
## 命名空间(或目录)
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
# 引用规范推送 `git push origin master:refs/heads/qa/master`
## Git 每次运行 `git push origin` 时都像上面这样推送
push = refs/heads/master:refs/heads/qa/master
引用规范的格式由一个可选的 +
号和紧随其后的 <src>:<dst>
组成,
其中 <src>
是一个模式(pattern),代表远程版本库中的引用;<dst>
是本地跟踪的远程引用的位置。+
号告诉 Git 即使在不能快进的情况下也要(强制)更新引用。
1) 如果服务器上有一个 master 分支,你可以在本地通过下面任意一种方式来访问该分支上的提交记录:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
上面的三个命令作用相同,因为 Git 会把它们都扩展成 refs/remotes/origin/master。
1) 如果有某些只希望被执行一次的操作,我们也可以在命令行指定引用规范。git fetch origin master:refs/remotes/origin/mymaster
1) 你也可以指定多个引用规范。 在命令行中,你可以按照如下的方式拉取多个分支:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
我们不能在模式中使用部分通配符
1) 但我们可以使用命名空间(或目录)来达到类似目的
### 引用规范推送$ git push origin master:refs/heads/qa/master
### 删除引用$ git push origin :topic
因为引用规范(的格式)是 <src>:<dst>
,所以上述命令把 <src>
留空,意味着把远程版本库的 topic 分支定义为空值,也就是删除它。$ git push origin --delete topic
Git 可以通过两种主要的方式在版本库之间传输数据:“哑(dumb)”协议和“智能(smart)”协议。
哑协议: 一个基于 HTTP 协议的只读版本库
在传输过程中,服务端不需要有针对 Git 特有的代码;抓取过程是一系列 HTTP 的 GET 请求,这种情况下,客户端可以推断出服务端 Git 仓库的布局。
智能协议
哑协议虽然很简单但效率略低,且它不能从客户端向服务端发送数据。
智能协议是更常用的传送数据的方法,但它需要在服务端运行一个进程,而这也是 Git 的智能之处——它可以读取本地数据,理解客户端有什么和需要什么,并为它生成合适的包文件。 总共有两组进程用于传输数据,它们分别负责上传和下载数据。
为了上传数据至远端,Git 使用 send-pack 和 receive-pack 进程。 运行在客户端上的 send-pack 进程连接到远端运行的 receive-pack 进程。
举例来说,在项目中使用命令 git push origin master 时, origin 是由基于 SSH 协议的 URL 所定义的。 Git 会运行 send-pack 进程,它会通过 SSH 连接你的服务器。 它会尝试通过 SSH 在服务端执行命令,就像这样:
当你在下载数据时, fetch-pack 和 upload-pack 进程就起作用了。 客户端启动 fetch-pack 进程,连接至远端的 upload-pack 进程,以协商后续传输的数据。
Git 会不定时地自动运行一个叫做 “auto gc” 的命令。
“gc” 代表垃圾回收,这个命令会做以下事情:收集所有松散对象并将它们放置到包文件中, 将多个包文件合并为一个大的包文件,移除与任何提交都不相关的陈旧对象。$ git gc --auto
这个命令通常并不会产生效果。 大约需要 7000 个以上的松散对象或超过 50 个的包文件才能让 Git 启动一次真正的 gc 命令。
你可以通过修改 gc.auto 与 gc.autopacklimit 的设置来改动这些数值。
gc 将会做的另一件事是打包你的引用到一个单独的文件。
为了保证效率 Git 会将它们移动到名为 .git/packed-refs 的文件中,
Git 会首先在 refs 目录中查找指定的引用,然后再到 packed-refs 文件中查找。
最方便,也是最常用的方法,是使用一个名叫 git reflog 的工具。
当你正在工作时,Git 会默默地记录每一次你改变 HEAD 时它的值。 每一次你提交或改变分支,引用日志都会被更新。
你可以通过创建一个新的分支指向这个提交来恢复它git branch recover-branch ab1afef
git log --pretty=oneline recover-branch
由于引用日志数据存放在 .git/logs/ 目录中,现在你已经没有引用日志了。
一种方式是使用 git fsck 实用工具,将会检查数据库的完整性。
如果使用一个 –full 选项运行它,它会向你显示出所有没有被其他对象指向的对象:
$_PS: stash 的丢失,也可以通过这个指令找出/恢复。----lost-found
: write dangling objects in .git/lost-found
当你迁移 Subversion 或 Perforce 仓库到 Git 的时候,这会是一个严重的问题
## 错误添加
$ curl https://www.kernel.org/pub/software/scm/git/git-2.1.0.tar.gz > git.tgz
$ git add git.tgz
$ git commit -m 'add git tarball'
## 其实这个项目并不需要这个巨大的压缩文件。 现在我们将它移除
git rm git.tgz
## 执行 gc 来查看数据库占用了多少空间
$ git gc
### 你也可以执行 count-objects 命令来快速的查看占用空间大小
git count-objects -v
size-pack 的数值指的是你的包文件以 KB 为单位计算的大小,所以你大约占用了 5MB 的空间。
在最后一次提交前,使用了不到 2KB ——显然,从之前的提交中移除文件并不能从历史中移除它。
首先你必须找到它。
但是假设你不知道;你可以通过运行 git verify-pack 命令, 然后对输出内容的第三列(即文件大小)进行排序,从而找出这个大文件。
你也可以将这个命令的执行结果通过管道传送给 tail 命令,因为你只需要找到列在最后的几个大对象。
$ git filter-branch --index-filter \
'git rm --ignore-unmatch --cached git.tgz' -- 7b30847^..
## 你的历史中将不再包含对那个文件的引用。 不过,你的引用日志和你在 .git/refs/original 通过
$ rm -Rf .git/refs/original
$ rm -Rf .git/logs/
$ git gc
## 让我们看看你省了多少空间。
$ git count-objects -v
## 这个大文件还在你的松散对象中,并没有消失;
## 如果真的想要删除它,可以通过有 --expire 选项的 git prune 命令来完全地移除那个对象
$ git prune --expire now
$ git count-objects -v
Git 总是在一个 bash shell 中运行,并借助一些 shell 环境变量来决定它的运行方式。
全局行为
GIT_EXEC_PATH
GIT_EDITOR
版本库位置
GIT_DIR
GIT_WORK_TREE
GIT_OBJECT_DIRECTORY
路径规则
GIT_GLOB_PATHSPECS 和 GIT_NOGLOB_PATHSPECS 控制通配符在路径规则中的默认行为。
GIT_LITERAL_PATHSPECS
GIT_ICASE_PATHSPECS
提交
GIT_AUTHOR_NAME, _EMAIL, _DATE
GIT_COMMITTER_NAME, .. , ..
网络
Git 使用 curl 库通过 HTTP 来完成网络操作, 所以 GIT_CURL_VERBOSE 告诉 Git 显示所有由那个库产生的消息。
GIT_SSL_NO_VERIFY
GIT_HTTP_LOW_SPEED_TIME
GIT_HTTP_USER_AGENT
比较和合并
GIT_DIFF_OPTS
GIT_EXTERNAL_DIFF
GIT_MERGE_VERBOSITY
调试
GIT_TRACE